鐵人賽在 Day 30 收官了。那篇的最後一段我寫：下一個三十篇如果存在，主題會是「跟一個管家過日子」，而它比「從零到一個管家」難得多。

這篇不是第二個三十篇的開頭。它比較像一張明信片——收官後十九天，我回頭看這一個月發生了什麼，發現它剛好把 Day 30 那個預言驗證了一輪：這一個月我幾乎沒加什麼「功能」，卻改掉了一批我以為早就對的假設。

三件事：管家終於看得到我的證券帳戶了；它在某個晚上九點對一條過期二十六天的規則叫了一聲；還有，一支手錶今天到貨，此刻正躺在桌上更新系統，等著配對。

每一件我都用同一個順序講：**出了什麼問題、為什麼會這樣、到底要解決什麼、用什麼方式做、換到了什麼、以及它接下來能長到哪。**因為這一個月最大的體會，就是「過日子」的工作跟「造東西」不同——它不是從需求開始，是從問題開始。

一、帳本是月刊，管家卻每天用它做決策

出了什麼問題

Day 18 講過投資分身的資料鏈：行情從免費來源抓、持倉寫在 Markdown 帳本裡、損益由腳本每天早上算。九月中盤點時，帳本的數字很難看：券商對帳單最後一份是八月底的，距今十六天；八月底的三筆成交，是兩週之後我才在對帳單上發現、才補進帳本。

這十六天裡，晨報、槓桿檢查、觸發線監控，全都在用一份過時的帳本做判斷。

為什麼會這樣

因為整條鏈裡，持倉是唯一手動維護的環節。行情有 API、損益是算出來的，但「我到底有幾股」的真相來源是券商每月寄來的對帳單 PDF——我看到、我改帳本、系統才知道。真相來源是月刊，決策是日刊，中間隔著一個人。

而且那份 PDF 的台股區沒有逐檔明細（Day 18 提過只有美股區能解析），所以連「自動讀對帳單」這條路都走不通。

要解決什麼

要解決的不是「帳本要準」——那是結果。要解決的是：讓系統每天有一份「券商說的」持倉、成交、交割款，不經過我這個人。

但這件事有一個前三十篇沒遇過的約束：券商 API 的帳戶是可以下單的。所以問題的完整版是——每天自動拿到帳戶事實，同時不引入任何下單的可能。我對 AI 助手說的第一句話是：「用最高標準，這牽扯實際的操作，逐步驗證。」

怎麼做

券商的 SDK 一裝進來，下單、改單、刪單的方法就跟查庫存的方法住在同一個物件裡。「我們只呼叫查詢的那幾個」是一句承諾，而 Day 24 講過：**個人系統最大的敵人是自己的隨性，制度是唯一有效的武器。**所以「唯讀」這件事做成了四層，每層獨立成立：

每一層背後都有一個「為什麼不放別處」：

• 為什麼獨立容器？ Day 27 講過，LLM 分身的容器裡有 shell 執行工具。交易憑證跟一個會執行指令的 Agent 住同一個檔案系統，等於把整套授權分級白做了。
• 為什麼憑證不能進 workspace？ workspace 會被同步到我的 Windows 機器（Day 13），也被儀表板容器、Agent 容器同時掛載。Day 26 的安全掃描抓過三個自己埋的漏洞，這次不想埋第四個。
• 為什麼要 CI 靜態掃描？ runtime 的白名單擋的是「執行時」；掃描擋的是「有人（包括未來的我）把下單碼寫進這個目錄」。兩個守的不是同一件事。
• 為什麼還要券商端只勾帳務查詢？ 因為前三層都在我的機器上，而我的機器有 Day 26 承認過的既有邊界。伺服器端的權限是唯一一層不在我手上、也就不會被我自己弄壞的。

第二個做法是閘門：整件事切成四個階段——骨架、模擬環境、正式環境唯讀、每日同步——每一階段進下一階段都要我點頭。這是把 Day 27「按破壞半徑分級授權」用在專案推進上：AI 可以把每一階段做完、驗完，但「要不要進下一階」是我的。

第三個做法是每一步都看輸出，而它真的抓到了東西。模擬環境八步探測全過，換上正式金鑰，登入成功——然後所有帳務端點集體回「IP 不合法」。查了才知道：券商的 IP 白名單只檢查帳務端點，登入、市場狀態、憑證查詢統統不檢查。**登入成功不代表白名單設對了。**如果沒有「一步一步跑、每步看輸出」這條規矩，這會是一個「昨天明明可以」的靈異故障。

最後是接進既有的鏈：每晚九點半（券商帳務更新之後）容器拉一次快照；隔天六點的持倉同步優先讀快照組台股持倉；快照缺席或超過七十二小時就退回靜態備援，並在報告上明講是備援——Day 18 那條「資料要帶自己的可信度」，這次一開始就有。守衛（Day 20）多了一段：超過二十六小時沒成功、憑證剩不到三十天、有人誤把正式金鑰放進同步範圍，都會告警。

換到了什麼

**持倉的延遲從「一個月」變成「隔天」。**這是最直接的。

但更值錢的是正式對帳那一晚——那個問題清單上編號 B1 的問題「帳本到底準不準」有了答案：不準。一檔持股，帳本說 15 股，券商說 17 股。多出來的兩股是九月初買的，兩筆都買在我自己設的觸發線上方——也就是說，我不只帳本記漏了，還違反了自己的紀律，而系統沒有任何一環知道。另外均價也對不上：券商給的是不含手續費的成交均價，帳本用的是「投資成本除以股數」的含費口徑。兩邊都沒錯，是口徑沒對齊。

三個裁決當晚做了：兩股寫回帳本；台股資料從此以 API 為主，均價統一含費口徑；交割帳戶餘額暫時只當資訊欄、不進帳本的現金（入帳口徑我還沒想清楚，不清楚就不要假裝清楚）。從那之後晨報和收尾報各多一行「🏦」，寫著昨晚同步成功與否、有沒有新成交。

接下來能長到哪

這個設計從第一天就替兩件事留了位置，而且刻意用「畫線」而不是「留路」的方式留：

• **多帳戶。**太太和小孩的帳戶也在申請 API。接法是一帳戶一把金鑰、一份憑證、一個容器 service，同一個映像檔、不同的憑證目錄與輸出目錄；主帳戶的持倉檔不混入家人持倉。加一個帳戶＝加一段設定，不改程式。
• **自動化交易。**接 API 那天我就說了未來想做。AI 的回應我很滿意——不是在唯讀模組裡預留一條下單路徑，而是把界線畫清楚：自動化交易是另一個模組、另一把金鑰、另一個憑證目錄、另一道閘門；唯讀 facade 和靜態掃描永遠不放寬。今天的骨架是為它鋪路，但鋪的是「旁邊那條路」，不是在這條路上留暗門。第一個候選策略，會是女兒帳戶的小額定期定額：獨立帳戶、ETF、小額、規則驅動、只買不賣。Day 30 那個單字遊戲的女兒，這次成了風險最低的實驗對象。

二、一條過期二十六天的規則，在晚上九點零五分叫了

出了什麼問題

API 接通的同一個晚上，我做了一次投資系列的整體審視。頭條不是新功能，是一則告警：九點零五分，觸發線監控發出「🔔 觸發」，某檔跌到我設的加碼線以下了。看起來一切正常——直到我翻出那條規則本身。它的動作欄寫著「8 月 19 日前執行」，而那天是九月十四日。**規則過期二十六天，引擎照叫。**更諷刺的是，正式對帳剛證明我在九月初已經在這條線上方買過了——這條規則早該被標成「已完成」或「作廢」。

為什麼會這樣

根因有兩層。

表層：觸發引擎只認價格條件，沒有「有效期限」的概念。「8/19 前執行」是我寫給自己看的散文，藏在動作欄裡，機器讀不到。

深層：**規則的生命週期沒被管理。**我的持倉在變、我的想法在變，而規則表沒有跟著變。一條寫在八月的規則，到了九月還在替我值班，忠實得可怕。這不是 bug，是「過日子」才會冒出來的問題——造系統的時候每條規則都是新的，過日子之後規則會自己過期。

要解決什麼

三件事，而且順序重要：

1. 過期或暫停的規則不能推播、不能亮紅燈，但狀態轉變要照樣記錄（歷史要留，不然事後說不清楚它有沒有碰過線）。
2. 判定「這條規則現在有沒有效」只能存在一個地方——三個頁面加晨報，誰自己判都會有一天跟別人不一樣。
3. 為自動化交易鋪地基。**一條會對過期規則叫的引擎，絕對不能接到下單模組上。**規則表要先變成機器完整可讀的東西，這是第 5 階段的前提，不是選配。

怎麼做

規則表加兩欄：「有效期限」（到當日為止含當日）與「狀態」（有效／暫停／已完成／作廢）。判定放在共用函式一處，回傳每列一個 active 旗標；觸發告警、晨報、觀察清單頁、持倉頁全部 require 同一份。過期的規則照樣寫進狀態檔（轉變紀錄不斷），但不推播；晨報另外列一段「⏰ 已過期待裁決」，把過期規則主動端到我面前，而不是安靜地失效。

換到了什麼

假觸發歸零，這是小的。大的是規則表變成了一份有生命週期的資產：每條規則都有生日、有到期日、有狀態，過期會被點名。以前的規則表是「我某天的想法快照」，現在是「系統知道哪些想法還算數」。

接下來能長到哪

這兩欄就是第 5 階段規則檔的雛形。設計案裡的自動化交易觸發來源，是一份結構化規則檔——含有效期限、含簽核欄——LLM 只能「提案」，提案必經規則引擎驗證。這個月加的「有效期限＋狀態＋一處判定」，正是那份規則檔第一版的欄位。規則沒清乾淨前，不能自動化——這句話現在寫在那份設計案的第一條。

同一個月的另外三筆學費

審視不只抓到那條規則。九月初我把底層框架升了一個大版本，之後陸續發現三個全部沉默的故障——每一個都是 Day 30「第四個錯誤：相信自己的監控」的續集：

• **通知投遞斷了八天，而排程狀態全綠。**升級後頻道路由少了一條綁定，所有走框架投遞的報告從那一刻起全部送不出去。但「投遞失敗」不寫進排程的狀態欄，五個監控面看到的都是「執行成功」。之所以沒察覺，是因為我最依賴的晨報和收尾報走的是自發送的另一條路（Day 20 那套零 LLM 腳本），它們照常到，把缺口蓋住了。
• **用量收集器失明三天，曲線停在某一天不動。**升級後執行軌跡從檔案改存資料庫，舊收集器掃到零個檔案照樣回報成功。Day 25 那條「量了半年卻是空值的費用曲線」修好沒多久，又以另一種方式空了一次。
• **每小時巡檢的守衛失明一天。**升級把排程的資料表換了結構——欄位改名、執行紀錄換了一張表——守衛讀不到東西，但「讀不到」被當成「沒有異常」。事後盤點，讀那張表的腳本有二十二支，逐一對帳。

三件事的原因一樣：升級動了資料的位置，監控還在看原來的位置，於是它看到的永遠是「沒事」。修法也一樣：每個監控補一條「來源為零就報錯」——零不是安靜的正常值，零是「我看不見了」；投遞失敗補進監控面；資料表結構列成清單，升級前後逐檔對。效益是把三種沉默失效都變成會叫的失效。而它給 Day 30 那句「連驗證本身也要被驗證」一個可執行的版本：每次升級後，先問每一道監控「你現在讀的還是那個地方嗎」。

三、一支手錶，和一條為它預留的管線

出了什麼問題

這件比較輕鬆，但同樣是從問題開始的。

季度目標表（Day 15）裡有一格「每週運動三次」，靠我手動打卡。實況是：運動了忘記打、隔週補打又記不清哪天——季末結算時那一格幾乎不可信。同時，健康資料其實一直都在——手機每天都在計步、記睡眠——只是鎖在手機裡，系統一無所知。太太也想看自己的。然後，手錶訂了、還沒到。

為什麼會這樣

因為沒有一條管線把 HealthKit 的東西帶進系統。「打卡」是人在替資料搬運，跟第一節的帳本是同一個病：真相在別的地方，系統靠人轉述。

要解決什麼

四件：運動打卡自動化（不再靠人）；健康數據有一頁可看（自己和太太）；資料不完整時不說謊（沒手錶就沒心率，不能畫成零）；手錶到貨那天不需要改程式。

最後一條是刻意放進需求的。手錶到貨是可預見的事件，如果那天要動程式，就代表設計時沒把「資料來源會變多」想進去。

怎麼做

手機上的家庭中控 App 會把 HealthKit 的感測值回報給家居中控（Day 5 那個）——這是現成的，不用寫。中控每十五分鐘進一次快取；每天凌晨一支零 LLM 腳本把當日結算成一列「22 項指標 × 每人」寫進 jsonl；儀表板多一頁健康頁：KPI 磚、步數長條加門檻線、睡眠堆疊、資料健康區。

幾個關鍵的設計決定：

• **步數過八千，自動打卡「運動」。**兩顆步數來源（計步器與 HealthKit）取最大值；只增不刪——人工刪掉的打卡不會被補回，零回報的日子不寫零。
• 三種「沒數字」分開講。「零回報」（那天手機沒回報）、「未結算」（還沒到結算時間）、「待接入」（HealthKit 說沒有來源）是三種不同的事實，頁面用三種不同的框畫，都不畫 0。沒有手錶，心率、血氧、睡眠分期就是「待接入」——一組灰磚，寫著「⌚ 等 Watch」。
• **人是一個清單。**太太的手機加進來，程式改的只是清單加一列；jsonl 每列帶人名鍵、健康頁一人一張卡、晨報多一行「↳」。
• **夜間推一把。**手機不開 App 就不回報，所以中控每晚 23:50 和早上 07:50 對兩支手機送一次靜默的「請更新位置」——iOS 收到會連感測器一起推，確保日界前至少回報一次。

順帶一個坑，跟第二節的形狀一模一樣：同一支 iPhone 在中控裡有三次註冊（App 升級留下的舊裝置），只有最後一個活著，前兩個保留著凍住的舊值。第一版管線綁到了死的那個，數字看起來完全合理——因為它們曾經是真的。分辨裝置活死要看時間戳有沒有在動，不要看數值大小。

換到了什麼

季目標那一格「運動達標週數」現在自動填——本季十三週，達標幾週，系統算的。晨報多一行「❤️ 昨日步數 · 打卡 · 手機回報次數」，收尾報多一行「今日步數 · 手機最後回報」；週報多一段兩人各一行。而健康頁的資料健康區能看到手機到底幾點回報過、夜間那一推有沒有命中——管線本身的健康也是資料，Day 20 的老規矩。

接下來能長到哪

手錶今天到了。此刻它在桌上更新系統，等一下配對。我對這件事的工程期待很具體：**一行程式都不需要改。**Watch 同步到 HealthKit → App 背景推送 → 中控 → 快取 → 結算 → 灰磚變亮。設計時就是照這個路徑鋪的。

明天早上八點，晨報那行 ❤️ 如果多了「睡眠 7h12m · 靜止心率 58」，代表整條管線的假設是對的。如果沒有，代表某一段的假設錯了——而依這個月的經驗，錯的地方通常不會報錯，只會安靜地維持灰色。所以我已經知道明早要看哪裡：不是看有沒有告警，是看那組灰磚有沒有消失。

再往後：加一個人＝清單加一列；加一項指標＝指標目錄加一列；早睡自動化還缺「就寢時刻」這個資料源（HealthKit 只給分鐘數），是下一個要決定的。

這一個月的形狀

Day 30 交了一張成績單，這篇交的是一張帳單。三件事並排看，會發現它們是同一個形狀：

跟管家過日子的第一個月，我學到的東西可以壓成一句：

每接進一個新的真相來源，就有一批舊假設被推翻。

券商 API 接進來，帳本錯了兩股、均價口徑錯了、我自己的紀律也破了一次；規則表被審視，發現一條忠實值班的過期規則；框架升級，三道監控同時看錯地方；手錶還沒到，管線已經先抓到一台幽靈裝置。沒有一件是「功能不夠」，全部是「原本以為對的東西其實不對」。

這也回答了 Day 30 那個問題——為什麼「跟管家過日子」比「造一個管家」難。造的時候，每個假設都是我親手寫的，錯了我知道；過日子的時候，假設會自己過期，而過期的假設跟正確的假設在儀表板上長得一模一樣。長期運營的核心工作不是加功能，是定期把「我以為」換成「我驗過」。

手錶更新好了。我去配對了——明天八點，晨報會告訴我這條管線的假設有沒有過關。

🔑 這篇的關鍵字
帳本是月刊、決策是日刊（真相來源的頻率決定決策的品質）· 唯讀要做到結構上做不到：券商端權限 · 唯讀 facade · CI 靜態掃描 · 憑證在同步範圍外，四層獨立成立 · 每階段進下一階段要人點頭 · 登入成功 ≠ 白名單設對 · 多帳戶＝加一段設定；自動化交易＝另一條路，不留暗門
規則有生命週期：有效期限不能藏在散文裡 · 一處判定、多處共讀 · 規則沒清乾淨前不能自動化
升級後先問每道監控「你讀的還是那個地方嗎」（零不是安靜的正常值，零是「我看不見了」）· 裝置活死看時間戳不看數值
三種「沒數字」分開講、都不畫零 · 人是清單、指標是目錄 · 手錶到貨零改碼 · 每接進一個真相來源，就有一批舊假設被推翻 · 長期運營＝定期把「我以為」換成「我驗過」

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。